KRaft簡介

?Kafka的共識機制KRaft，仍然處于預覽機制。未來KRaft將作為Apache Kafka的內置共識機制將取代Zookeeper。該模式在2.8版本當中就已經發(fā)布了體驗版本，在3.X系列中KRaft是一個穩(wěn)定release版本。
KRaft運行模式的kafka集群，不會將元數(shù)據(jù)存儲在zookeeper中，即部署新集群的時候，無需部署zk集群，因為Kafka將元數(shù)據(jù)存儲在Controller節(jié)點的KRaft Quorum中。KRAFT可以帶來很多好處，比如可以支持更多的分區(qū)，更快速的切換Controller，也可以避免Controller緩存的元數(shù)據(jù)和zk存儲的數(shù)據(jù)不一致帶來的一系列問題。

KRaft架構

首先來看一下KRaft在系統(tǒng)架構層面和之前的版本有什么區(qū)別。KRaft模式提出來去zookeeper后的kafka整體架構入下圖是前后架構圖對比：

在當前架構中，一個kafka集群包含多個broker節(jié)點個一個ZooKeeper集群。我們在這張圖中描繪了一個典型的集群結構：4個broker節(jié)點個3個ZooKeeper節(jié)點。kafka集群的Controller（橙色）在被選中后，會從ZooKeeper中加載他的狀態(tài)。Controller指向其他Broker節(jié)點的箭頭表示Controller在通知其他briker發(fā)生了變更，如Leaderanddisr和Updatemetdata請求。

在新的架構中，3個Controller節(jié)點代替三個ZooKeeper節(jié)點。控制器節(jié)點和Broker節(jié)點在不同的進程中。Controller節(jié)點中會選擇一個成為Leader（橙色）。新架構中，控制器不會想Broker推送更新，而是Broker從這個Controller Leader拉取元數(shù)據(jù)的更新信息。

注意：盡管Controller進程在邏輯上與Broker進程是分離的，但他們不需要再物理上分離，即在某些情況下，部分所有Controller進程和Broker進程可以使同一個進程，即一個broker節(jié)點即是Broker也是Controller。另外在同一個節(jié)點上可以運行兩個進程，一個是Controller進程，一個是broker進程，這相當于在較小的及群眾。Zookeeper進程可以想Kafka Broker一樣部署在相同的節(jié)點上。

部署

首先目前官方頁面上并沒有集群搭建文檔。我們下載安裝包，查看config/kraft下的README.md文件。可以看到詳細說明。

根據(jù)說明，這里我搭建Kraft模式的kafka集群。這里我用的是3.1版本

這里我準備三臺機器：

下載

官網下載

上傳服務器并解壓

這里我在node2機器上傳到自己的目錄下/home/guohao

cd /home/guohao
#解壓
tar -zxvf kafka_2.13-3.1.0.tgz
cd /home/guohao/kafka_2.13-3.1.0/

配置server.properties

cd config/kraft/
vi server.properties
# 節(jié)點角色
process.roles=broker,controller
?
#節(jié)點ID，和節(jié)點所承擔的角色想關聯(lián)
node.id=1
?
# 集群地址
controller.quorum.voters=1@192.168.0.113:9093,2@192.168.0.114:9093,3@192.168.0.115:9093
?
#本機節(jié)點
listeners=PLAINTEXT://192.168.0.113:9092,CONTROLLER://192.168.0.113:9093
?
# 這里我修改了日志文件的路徑，默認是在/tmp目錄下的
log.dirs=/home/guohao/kafka_2.13-3.1.0/kraftlog/kraft-combined-logs

Process.Roles

每個Kafka服務器現(xiàn)在都有一個新的配置項，叫做Process.Roles, 這個參數(shù)可以有以下值:

• 如果Process.Roles = Broker, 服務器在KRaft模式中充當 Broker。
• 如果Process.Roles = Controller, 服務器在KRaft模式下充當 Controller。

• 如果Process.Roles = Broker,Controller，服務器在KRaft模式中同時充當 Broker 和Controller。
• 如果process.roles 沒有設置。那么集群就假定是運行在ZooKeeper模式下。

如前所述，目前不能在不重新格式化目錄的情況下在ZooKeeper模式和KRaft模式之間來回轉換。同時充當Broker和Controller的節(jié)點稱為“組合”節(jié)點。

對于簡單的場景，組合節(jié)點更容易運行和部署，可以避免多進程運行時，JVM帶來的相關的固定內存開銷。關鍵的缺點是，控制器將較少地與系統(tǒng)的其余部分隔離。例如，如果代理上的活動導致內存不足，則服務器的控制器部分不會與該OOM條件隔離。

Quorum Voters

系統(tǒng)中的所有節(jié)點都必須設置 `controller.quorum.voters` 配置。這個配置標識有哪些節(jié)點是 Quorum 的投票者節(jié)點。所有想成為控制器的節(jié)點都需要包含在這個配置里面。這類似于在使用ZooKeeper時，使用ZooKeeper.connect配置時必須包含所有的ZooKeeper服務器。

然而，與ZooKeeper配置不同的是，`controller.quorum.voters` 配置需要包含每個節(jié)點的id。格式為: id1@host1:port1,id2@host2:port2。

分發(fā)并配置

cd /home/guohao
#解壓
tar -zxvf kafka_2.13-3.1.0.tgz
cd /home/guohao/kafka_2.13-3.1.0/

#node3 server.properties
# 節(jié)點角色
process.roles=broker,controller
?
#節(jié)點ID，和節(jié)點所承擔的角色想關聯(lián)
node.id=2
?
# 集群地址
controller.quorum.voters=1@192.168.0.113:9093,2@192.168.0.114:9093,3@192.168.0.115:9093
?
#本機節(jié)點
listeners=PLAINTEXT://192.168.0.114:9092,CONTROLLER://192.168.0.114:9093
?
# 這里我修改了日志文件的路徑，默認是在/tmp目錄下的
log.dirs=/home/guohao/kafka_2.13-3.1.0/kraftlog/kraft-combined-logs

#node4 server.properties
# 節(jié)點角色
process.roles=broker,controller
?
#節(jié)點ID，和節(jié)點所承擔的角色想關聯(lián)
node.id=3
?
# 集群地址
controller.quorum.voters=1@192.168.0.113:9093,2@192.168.0.114:9093,3@192.168.0.115:9093
?
#本機節(jié)點
listeners=PLAINTEXT://192.168.0.115:9092,CONTROLLER://192.168.0.115:9093
?
# 這里我修改了日志文件的路徑，默認是在/tmp目錄下的
log.dirs=/home/guohao/kafka_2.13-3.1.0/kraftlog/kraft-combined-logs

運行KRaft集群

運行KRaft集群，主要分為三步：

• 用kafka-storage.sh 生成一個唯一的集群ID

./bin/kafka-storage.sh random-uuid

#會生成一個uuid 

• 用kafka-storage.sh 格式化存儲數(shù)據(jù)的目錄

1. ?
   #每個節(jié)點都要執(zhí)行
2. ?
   #./bin/kafka-storage.sh format -t <uuid> -c ./config/kraft/server.properties
3. ?
   ./bin/kafka-storage.sh format -t 04ofzeqFRgqBWQGtLEqmNQ -c ./config/kraft/server.properties

• 用bin/kafka-server-start.sh 啟動Kafka Server

1. ?
   #每個節(jié)點都要執(zhí)行
2. ?
   ./bin/kafka-server-start.sh ./config/kraft/server.properties

運行KRaft集群

運行KRaft集群，主要分為三步：

• 用kafka-storage.sh 生成一個唯一的集群ID

./bin/kafka-storage.sh random-uuid

#會生成一個uuid 

• 用kafka-storage.sh 格式化存儲數(shù)據(jù)的目錄

1. ?
   #每個節(jié)點都要執(zhí)行
2. ?
   #./bin/kafka-storage.sh format -t <uuid> -c ./config/kraft/server.properties
3. ?
   ./bin/kafka-storage.sh format -t 04ofzeqFRgqBWQGtLEqmNQ -c ./config/kraft/server.properties

• 用bin/kafka-server-start.sh 啟動Kafka Server

1. ?
   #每個節(jié)點都要執(zhí)行
2. ?
   ./bin/kafka-server-start.sh ./config/kraft/server.properties

實用工具

使用過程中，如果遇到問題，可能需要查看元數(shù)據(jù)日志。在KRaft中，有兩個命令行工具需要特別關注下。kafka-dump-log.sh和kafka-metadata-shell.log。

KRaft模式下 ，原先保存在Zookeeper上的數(shù)據(jù)，全部轉移到了一個內部的Topic：@metadata上了。比如Broker信息，Topic信息等等。所以我們需要有一個工具查看當前的數(shù)據(jù)內容。

Kafka-dump-log.sh是一個之前就有的工具，用來查看Topic的的文件內容。這工具加了一個參數(shù)--cluster-metadata-decoder用來，查看元數(shù)據(jù)日志，

平時我們用zk的時候，習慣了用zk命令行查看數(shù)據(jù)，簡單快捷。bin目錄下自帶了kafka-metadata-shell.sh工具，可以允許你像zk一樣方便的查看數(shù)據(jù)。

總結

Kafka 經常被認為是一個重量級的基礎設施，管理Apache Zookeeper的復雜性就是這種看法存在的重要原因。而KRaft模式提供了一種很棒的、輕量級的方式來開始使用Kafka，或者可以使用它作為ActiveMQ或RabbitMQ等消息隊列的替代方案。